Legacy file systems, such as variants of the File Allocation Table (FAT) system, continue to enjoy wide acceptance. Even if not used as the main system storage format, such legacy file systems may still be implemented as a means of data interchange between computerized systems that normally use incompatible media formats.
Unfortunately, such legacy file systems are usually not optimized or able to be optimized for some modern storage media types, such as flash memory. Legacy file systems also tend to be limited in function by historical constraints which are no longer present in more modem file systems.
Thus, it becomes useful to implement virtual access to these legacy file systems while actually storing the data using a more optimal physical file format. This mapping between file system formats can be done using a network file system or some other abstraction that hides the physical format of the storage media from its clients. However, some remote data access and interchange mechanisms still must ultimately expose the storage media format to the client. For example, the USB Mass Storage Class protocol and the iSCSI network storage protocol expose storage media at the block allocation level. Consequently, only physical storage formats understood by both the remote client and the local storage devices can be used, leading to a prevalence of FAT-formatted file systems in the presently available local storage devices, even when such a format is not optimal for the actual storage media on the device.
Furthermore, exposing the storage media at the block (instead of file system) level hides the file system operations from the storage device. If the device then needs to do maintenance operations related to file additions, changes, or deletions, it has to compare the state of the file system before and after the block operations are performed in order to determine if files have been changed. An example of this is a USB device that exposes its storage media over the Mass Storage Class protocol while also maintaining a database of media files that are stored in the file system. A remote USB host using the device's storage media in block mode may not know how to update the database when files are added or deleted, so the entire media needs to be rescanned and the database rebuilt after every USB session completes. This can be a very time-intensive operation for large storage media.
FIG. 1 (background art) is a block diagram illustrating the problems noted above. A computerized system 10 includes a host or client 12, a storage server 14, and a communications link 16 between the client 12 and the storage server 14. Typically, although not necessarily, the client 12 and the storage server 14 are somewhat “remote” from each other, usually by at least a few inches or tens of centimeters.
For example, the client 12 may be a personal computer (PC), the storage server 14 may be an external hard drive or “thumbnail” flash memory unit, and the communications link 16 may be an USB Mass Storage Class or iSCSI network storage.
The client 12 includes an operating system filesystem (OS FS 18) (e.g., a Windows™filesystem), a legacy filesystem 20 (e.g., a FAT filsesystem), and a first network filesystem interface 22. For the sake of comparison, a legacy local storage 24 is also shown (e.g., a hard drive formatted with the FAT filesystem).
The storage server 14 includes a second network filesystem interface 26, a local filesystem controller 28, and sectored or block storage media 30. In particular, the network filesystem interfaces 22, 26 here must be able to work with the protocol (i.e., a legacy filesystem 20) being employed across the communications link 16—because there is no mechanism in this scheme to permit otherwise.
Accordingly, to eliminate the need to use FAT or other legacy file systems and to offer the opportunity to map operations at the block device level to equivalent file system operations, what is needed is a way to expose a virtual legacy format, such as FAT, on a storage device that actually uses another, presumably more optimal, file system for its physical media format.